1. Technical Field
The present invention relates generally to execution of Web-based applications in a content delivery network.
2. Description of the Related Art
Enterprises can expand their business, increase efficiency, and enable new revenue streams by extending their business applications over the Internet to customers, partners, and suppliers. One way to enable enterprises to shift the operational burden of running a reliable and secure Web presence is to outsource that presence, in whole or in part, to a service provider, such as a content delivery network (CDN). A content delivery network is a collection of content servers and associated control mechanisms that offload work from Web site origin servers by delivering content (e.g., Web objects, streaming media, HTML and executable code) on their behalf to end users. Typically, the content servers are located at the “edge” of the Internet. A well-managed CDN achieves this goal by serving some or all of the contents of a site's Web pages, thereby reducing the customer's infrastructure costs while enhancing an end user's browsing experience from the site. In operation, the CDN uses a request routing mechanism to locate a CDN edge server electronically close to the client to serve a request directed to the CDN. Sites that use a CDN benefit from the scalability, superior performance, and availability of the CDN service provider's outsourced infrastructure.
Many enterprises, such as those that outsource their content delivery requirements, also implement their business services as multi-tier (n-tier) applications. In a representative n-tiered application, Web-based technologies are used as an outer (a first or “presentation”) tier to interface users to the application, and one or more other tiers comprise middleware that provides the core business logic and/or that integrates the application with existing enterprise information systems. The Java 2 Platform, Enterprise Edition (J2EE™) is a technology and an associated component-based model that reduces the cost and complexity of developing such multi-tier, enterprise services. The J2EE runtime environment defines several types of application components that can be used to build services. These include (a) Web tier components (e.g., servlets, JSP pages, Java beans, filters, and web event listeners), which are components that typically execute in a web server and respond to HTTP requests from web clients, and (b) Enterprise tier components (e.g., session beans, entity beans and message driven beans, which may be developed as Enterprise JavaBeans™ (EJB™)), that include the business logic and that execute in a managed environment to support transactions. Runtime support for J2EE application components are provided by so-called “containers,” with a Web container supporting the Web tier components, and an Enterprise container supporting the Enterprise tier components. Containers execute the application components and provide utility services. J2EE-compliant servers provide deployment, management and execution support for conforming application components.
The provisioning of server-side Java applications or application components to run on CDN edge servers presents complex deployment and operational issues. A solution is described in commonly-owned, copending application Ser. No. 10/340,206, filed Jan. 10, 2003, titled “Java Application Framework For Use In A Content Delivery Network.” According to that application, given edge servers in the CDN are provisioned with application server code used to execute Web tier components of an application (an “edge-enabled application”). In an illustrative embodiment, these application servers (appserver) are run out of process from a CDN server manager process, preferably one for every customer. Child appserver processes are forked/exec'd from the CDN server manager process, after which they are tightly monitored and controlled by a Java Manager subsystem. The CDN server manager process forwards a client request that requires appserver processing over local TCP socket to a child appserver process, which processes the request, and sends the response on the same connection. In addition, resource utilization load is reported from each appserver process, preferably across a shared memory segment, to the Java Manager subsystem. The Java Manager subsystem tightly monitors resource utilization of each child appserver process and will kill appserver processes that over utilize resources.
Java application servers typically are started on-demand, as in-bound requests are mapped to web applications (sometime referred to as “webapps”). Each application server process may also map to a content provider (i.e., a customer) code, so if an in-bound request maps to a webapp on a customer code for which no application server process is running, a new application server process may be started. Once started, the webapp can be installed in this application server process, and once installed, the request can be serviced.
If application server processes continue to spawn on demand, resources on the machine may start to run out so that it may not be possible to start another application server process on that machine. Because application servers may take on the order of 30-60 seconds to start and load, and because web applications can also take on the order of 10-20 seconds to load, misses for application processing requests can expensive from a request latency perspective. Indeed, spawning application servers in an on-demand fashion may lead the CDN server manager process into an undesirable state, where it is launching an application server for each new customer code that is requested, and it may deny service to requests when it hits a resource limit.
The present invention addresses this problem.